Same here, I'm on iOS 18.1 developer beta and see the same issue on Xcode 16 and 16.1

init will get called multiple times, so you might be running Into an issue where the value is getting toggled (not clear from this snippet) do as little work in the init as possible. If you want to set a value do it in onAppear or task modifier

The reason it goes away is that Apple now makes CKRecord conform to Sendable https://developer.apple.com/documentation/cloudkit/ckrecord?changes=latest_minor

You can just combine these two predicates in the predicate builder. Assuming your compound1 looks like myEntity.field1 == true and compound2 looks like myEntity.field2 == false you can write #Predicate { myEntity in myEntity.field1 == true || myEntity.field2 == false } for an AND variant you can do #Predicate { myEntity in myEntity.field1 == true && myEntity.field2 == false }

As others have said, it's probably a good idea to have your own unique id (UUID is probably the easiest way). I believe the core data PersistentIdentifier.ID may only be unique to the record on the current install of the current device. If you're doing syncing and want to reference a record on another device, it might not return the same PersistentIdentifier.ID.

I've played around with this, trying a lot of solutions, but I might have found a way to do case insensitive compare. In the SwiftData SampleTrips sample project I changed let filteredList = try? trip.bucketList.filter(#Predicate { item in item.title.contains(searchText) && tripName == item.trip?.name }) to: let filteredList = try? trip.bucketList.filter(#Predicate { item in return item.title.localizedLowercase.contains(searchText.localizedLowercase) && tripName == item.trip?.name }) This seemed to work. It seems the macro has support for localizedLowercase but not for lowerCased() Hope that helps. I'm a lot more excited about SwiftData now.

I think you want to change @Binding to @Bindable from: struct ListView: View { @Binding var listDataArray: [DataType] } to: struct ListView: View { @Bindable var listDataArray: [DataType] } I worry that you might have unexpected consequences to add the @Bindable in the body

Do the query and data case match? It doesn’t currently support case insensitive queries. A major oversight on their part. I filed a bug and you should too if this is your issue. If the issue is the relationship, you should file that too.

I ran into this too. I tried a few different ways that didn't work. Using combine to observe the values didn't work, but I did some digging and found something that might be viable, although it's a little convoluted. So @Observable is not just making something conform to ObservableObject, it's its own thing, it's writing some of your code for you. So if you expand the macro (right click on @Observable) it will expand the code it's augmenting your code with. You'll see a bunch of @ObservationTracked macros revealed for your properties. There's some other stuff too, but not specific to your property. @ObservationTracked var test: String = "" ... @ObservationIgnored private var _test: String If you expand that macro you now see the getter and setter for your property: @ObservationTracked var test: String = "" { get { access(keyPath: \.test) return _test } set { withMutation(keyPath: \.test) { _test = newValue } } } ... @ObservationIgnored private var _test: String Now you have hooks into setting the new value. So you can do something like this: @ObservationIgnored #Flip this to ignored because you're doing your own manual getter/setter# var test: String { get { access(keyPath: \.test) return _test } set { withMutation(keyPath: \.test) { _test = newValue #do your cool thing here# } } } ... @ObservationIgnored private var _test: String = "" #don't forget to move your initial value here# So with very light testing this seemed to work as expected. YMMV. I think we'll just have to see if this is a pattern, or if Apple can provide us a way to annotate properties we want a didSet hook for. Either way this might be the exact kind of use case we could write our own macro for. But I'd prefer if Apple solves this. I'm going to file a bug with Apple immediately to request they give us a built in solution. If we want to get it fixed, I think Apple needs to hear about and very soon so it still has a chance in getting in this year.

Fixed! Double check the capitalization of your project path vs your folder capitalization. When mine were mismatched (e.g. /Users/username/Git/Path/To/Project/Project.xcodeproj with a folder path of /Users/username/git/path/to/project/project.xcodeproj) I had this problem. Once I updated them to match the capitalization It worked. In Xcode select the project (first item in navigation list), show the file inspector and look at where it says Full Path, then compare to your folder structure in Finder

Just so this gets bubbled up more this answer colink (Apple wouldn't let me post a direct link ) about mid-way through the comments solved it for me. The tldr; is double check that the groups in your Xcode project have the same capitalization as the folders on disk. Mine had a discrepancy between the root folder name capitalization. Now my errors reliably show. Thank you colink

Experiencing the same on Xcode 14.2

Still seeing in Xcode 14.0.1

This is happening to me too, I was hoping this post would help me out. I've been suffering from this for several days, so not resolving for me. One thing I'm curious about, are you using a Watch App + Extension (old style) or just a Watch App? Apple's example code is still using the old style and works perfectly. For me, the watch can send messages to the phone, but the reply never comes back to the watch.

I'm having the same issue, I've tried both on Monterey and Big Sur. I think we'll need to wait for an update of Xcode.